[ゼロから始めるプロジェクトマネジメント] プロジェクトのスコープを稼働率を使ってリリース日から逆算しよう

情報システム室の進地＠日比谷です。

プロジェクトのスコープを決める時にプロジェクトメンバーの稼働率を求めて使うと便利です。 今回は、私が普段実践している、稼働率の算定方法と、それを用いたプロジェクトスコープの決定方法について記載します。

必ず担当者に見積をしてもらう

スコープを決定するにあたっては各工程の見積が必要ですが、見積は必ずその工程、機能を担当する担当者に行ってもらってください。たとえ、貴方がスーパーエンジニアで、担当者よりも当該システムの技術的要素や背景を知り尽くしていたとしても、というよりむしろそうであればあるほど、担当者ではない貴方が見積を行ってはいけません。

見積はなるべく正確に出す必要があります。そして、他者の置かれた複雑な状況（それまでの教育、知識、経験、得意・不得意、公私で抱えている問題のあれやこれや）を再現できない以上、担当者が出した見積が最も正確である確率が高いのです。もちろん、要件を勘違いしていたり、あまりにも非効率な設計を想定していると思われる場合には介入も必要なこともありますが、そうでない限りは担当者が出した見積はそのまま受け取ってください。

ただし、前提はあらかじめ揃えておいてください。例えば、結合テストは別途工数を取って設けるので、各製造タスクには含めないなど。こうした認識がずれていると色々と無駄な工数が発生したり、漏れが発生したりします。

各担当者毎に稼働率を割り出す

担当者毎に稼働率は異なります。ビジネスの世界には昔から人間は交換可能であると思いたがる信仰がありますが、残念ながら人間は交換可能ではありません。これは大事なポイントです。人間は交換可能ではありません。大事なことなので２回書きました。

ということで、各担当者毎に稼働率は当然異なります。特に複数のプロジェクトを掛け持ちしているような担当者の稼働率には注意を払う必要があります¹。貴方がピープルマネージャーも兼ねているのであれば、稼働率は貴方が出せるかもしれませんが、ここも基本的には各担当者に出してもらうのが良いです。その時に、「一ヶ月に20%ぐらい稼働できますかねー」といった感じでは誤差が大きくなるので、1日（8時間）中の何時間稼働できるか？を確認するようにしましょう。2時間という回答だったら25%です。こうして、各担当者の稼働率を洗い出しましょう。

稼働率に七掛けする

車間距離を取らずに運転すると衝突事故が発生しやすくなるように、バッファを取らずにプロジェクトをマネジメントすると事故が発生しやすくなります。バッファ（車間距離）は必ずとってください。どんな理由をつけてでもいいので取るようにしてください。「お客様が納得しない！」という向きもあるかと思いますが、納得しようとしまいと、事故ったら困るのはお客様なので、なんとか確保してください²。

プロジェクトチームの置かれた状況やパフォーマンスによって最適値は異なってくるのですが、私の経験では大体平均して稼働率を七掛けしておくと良いです。例えば、チームメンバーのAさんが25%稼働率なら、七掛けして、17%（小数点以下切り捨て）とします。

稼働率とリリース日から逆算してスコープを決定する

さて、七掛けした稼働率を求めたら、あとはリリース日からスコープを逆算していきます。

リリース日が三ヶ月後だとしたら、まずは正確な残営業日を算出します。ここも各メンバーにとっての残営業日を求められると一番良いです。連休、有給や病欠、急な不幸など色々ありますから。ただ、さすがに煩雑にすぎる向きもあるので、休みが多そうなメンバーの稼働率は七掛けから六掛けに変更するなど微調整することにし、ざっくり1ヶ月20営業日と算定しても良いと思います。

3ヶ月だと約60営業日なので、これにそれぞれのメンバーの稼働率を掛けます。七掛けした稼働率が17%だったAさんなら、60 x 0.17 = 10人日（小数点以下切り捨て）　となります。つまり、Aさんにはリリース日までに10人日しか工数がないということが明確になるわけです。同じように他のメンバーに関しても稼働率をかけて工数を出していきましょう。

各自がこのプロジェクトにリリース日までに供出できる工数が出せたら、それを合算してとやりたくなるところですがそれはNGです。何故かというと、もう一度重要なので書くのですが、人間は交換可能ではないからです。AさんはAさんが担当する工程、機能に対してAさんが担当したら対応できる工数を算定しているわけなので、Bさんが担当してしまったらまた工数は変わってしまうわけです。

ということで、Aさんが担当する工程、機能に関して10人日ならどこまで対応できるかという視点で対応順序を決めていきます。一般的に工数はかなり限られるはずですので、お客様、プロジェクトにとって最も価値の高いものに絞って工数を割り当てることになると思います。この時、例えば「検索機能が5人日、商品一覧機能が6人日で合わせて11人日か。約10人日なのでAさんになんとか頑張ってもらって」とか考えないでください。実際にプロジェクトが走り始めたら頑張ってもらう状況は必ず発生し得ます。不可抗力というものがありますから。だから、それゆえに、計画時点で担当者の頑張りを絶対に織り込まないでください。10人日と工数が出ているなら、Aさんの稼働は計画上10人日以下にしてください。

各メンバーに対して対応工程、機能の割り当てをおこなったら、それでリリース可能な状態になっているかを確認します。例えば、機能が中途半端でエンドユーザが使える状態になっていなければリリースはできないので、そこでPMはリリース日の調整や追加リソースの検討をしたり、例えば管理側の機能だけリリースしたりなどスコープの調整をお客様と行います。

計画の本当の価値

プロジェクトが走り出すと、様々な変更要求が発生します。人間が未来を予測できない以上、これは正常なことです。その際、今回述べたような根拠をもってスコープを決めておくと、変更のインパクトを論理立てて説明することができます。例えば、Aさんはフロントエンドの担当者だとして、3ヶ月で10人日といとペースは見えているので、フロントエンドに5人日の追加要件が発生したら、1.5ヶ月スケジュールが最低でも押すという判断ができます。

だいたいのお客様はリスケジュールにそのものに対して怒るのではありません³。それがプロジェクトの終盤になって急に知らされたり、説明の根拠がよくわからなかったりすることで、侮られたと感じたり不安に感じたりして怒るのです。3分でできるカップラーメンが1分でできないといって怒る人は稀です。3分かかるものはかかるのです。しかし、それが3分かかることが最初に明示されていなかったり、2分58秒になって10分かかりますとか言われたら怒るでしょう。こうしたことが起こらないようにするためには、丁寧に計画を立てておいて、計画とのずれを丁寧に説明していくという姿勢が欠かせません。

計画は立てても変わるから意味がない、そいういう意見もありますが、私は違うと思います。計画は説明責任を果たすため、お客様や関係者とコミュニケーションを取るために立てるのです。